本章目標

讀完這一章，你會建立第一個 Lovable 專案，並理解它不是一個孤立的生成結果，而是 workspace（工作區）裡的一個可持續迭代的 application。你會知道帳號、workspace（工作區）、project（專案）、dashboard（儀表板）、提示詞input、Build/Plan mode、preview（預覽）、settings、search、folders 之間的關係。

這章不追求把每個按鈕都背起來。更重要的是建立工作台心智模型：你從 dashboard（儀表板） 啟動專案，在 project（專案）裡和 Lovable 協作，透過 preview（預覽） 和 history 檢查變更，必要時整理資料夾、調整 access，最後再進入 publish 和 production（正式上線）flow。

為什麼這一章重要

很多人第一次用 AI 開發工具時，會把第一個提示詞看得太重。好像第一句話下得好，產品就會成功；第一句話下得不好，專案就完了。

Lovable 的工作方式不是這樣。

第一個提示詞只是起點。真正重要的是你如何把一個專案持續推進：什麼時候規劃、什麼時候實作、怎麼看 preview（預覽）、怎麼回復版本、怎麼保存專案背景、怎麼管理 workspace（工作區）裡越來越多的專案。

如果你只會在首頁輸入 提示詞，你會覺得 Lovable 像玩具。如果你理解 dashboard（儀表板） 和 project（專案）的結構，你會開始把它當成產品工作台。

思考模型：Account、workspace（工作區）、project（專案）

開始前先釐清三個層次。

Account 是你的個人身份。你用它登入 Lovable，管理個人資料、偏好、linked accounts、2FA 等設定。

Workspace（工作區） 是工作發生的地方。它保存 projects、members、billing、credits 和團隊設定。你可以有一個個人 workspace（工作區），也可以被邀請進團隊 workspace（工作區）。

Project（專案） 是一個具體 application。每個 project（專案）有自己的程式碼、chat history、preview（預覽）、settings、integrations 和 access control。

你可以把它想成：

Account = 你
Workspace = 你的工作場域
Project = 你正在打造的一個應用程式

這個區分很重要。當你未來開始做客戶案、團隊專案或內部工具時，很多問題不是「Lovable 會不會做」，而是「這個 project（專案）放在哪個 workspace（工作區）」、「誰有權限看到」、「用誰的 credits」、「要不要同步到 GitHub」、「要不要公開發布」。

步驟 1：建立帳號

你可以用 Email/password、Google、GitHub、Apple，或組織設定好的 SSO 建立 Lovable account。註冊後，Lovable 會建立第一個 personal workspace（工作區），讓你可以從免費方案開始使用。

這裡先不要急著研究每個方案。第一個任務是確認三件事：

• 你能登入。
• 你進得了 dashboard（儀表板）。
• 你知道現在所在的 workspace（工作區）是哪一個。

如果你是個人創作者或 indie maker，一開始用 personal workspace（工作區）就夠了。如果你在公司或團隊裡使用，先確認是不是應該進公司 workspace（工作區），而不是把正式專案開在個人 workspace（工作區）。

步驟 2：認識 dashboard（儀表板）

Dashboard（儀表板） 是 Lovable 的 home base。你會在這裡：

• 開新專案。
• 找到既有專案。
• 切換 workspace（工作區）。
• 進入 workspace（工作區）settings。
• 管理 connectors 和 resources。
• 查看最近開過的 projects。

最顯眼的是中央的 提示詞input。你可以直接輸入想做的 app，Lovable 會用這段描述建立新 project（專案）。

但 提示詞input 旁邊還有幾個你需要注意的能力：

• + menu 可以附加圖片或檔案，也可以接設計、backend（後端）、connectors 等上下文。
• mode toggle 可以在 Build 和 Plan 之間切換。
• project（專案）access 可以控制誰能看到或編輯專案。

換句話說，開新專案不是只有「輸入一句話」。你其實可以在開始前就決定：要不要先規劃、要不要附圖片、要不要接 backend（後端）、這個 project（專案）是個人測試還是 workspace（工作區）內可見。

圖 2-1：建立專案前可以先補上檔案、設計、connector 或 database 上下文，並在輸入框右側確認目前使用的是 Plan 模式。

步驟 3：第一個專案不要做太大

第一個 Lovable project（專案）的目標不是完成商業產品，而是熟悉 workflow（工作流）。

建議你做一個小到可以一天內理解的專案，例如：

• SaaS landing page 加上 lead form。
• 個人作品集網站。
• 小型活動報名頁。
• 內部工具 dashboard（儀表板） 假資料版。
• AI 工具的 landing page 和輸入介面。

避免第一個專案就做：

• Marketplace。
• 大型社群平台。
• 多角色後台。
• 複雜金流與發票。
• 需要大量外部 API 的產品。

不是因為 Lovable 不能做，而是因為你還沒熟悉如何規劃、驗證、回復和整理專案。第一個專案應該讓你練習工作流，不是考驗你能不能一次駕馭所有複雜度。

步驟 4：用 Plan Mode 開始，而不是急著 Build

Dashboard（儀表板） 的 mode toggle 很關鍵。Build 是預設執行模式，Lovable 會直接產生或修改程式。Plan 則用來討論和規劃，不會改 project（專案）。

第一個專案，我建議你先用 Plan Mode。

例如：

我想建立第一個 Lovable 專案。
這是一個為台灣 AI 寫作工具設計的產品介紹頁。
目標使用者是內容創作者和小型行銷團隊。
建置前，請協助我定義第一版。
請建議需要哪些頁面、區塊和資料，並說明目前應該暫緩哪些功能。
先不要寫程式碼。

這段 提示詞的目的不是炫技，而是讓 Lovable 幫你收斂第一版範圍。你要先知道自己要做什麼，再讓 Build Mode 動手。

步驟 5：再切到 Build Mode 建立第一版

當你看過 Lovable 的規劃後，可以把第一版範圍整理成 Build Mode（建置模式）提示詞。

請建置這個產品介紹頁的第一版。
請採用我們已確認的範圍：
- 清楚呈現產品定位的主視覺區塊
- 三個功能介紹區塊
- 簡單的價格預告
- 包含姓名、電子郵件和公司欄位的潛在客戶表單
- 常見問題區塊

請使用適合台灣使用者的繁體中文文案。
目前不要加入登入、付款或後端功能。
建置完成後，請摘要說明修改了哪些檔案或區域。

注意這裡有三個控制點：

• 指定要做什麼。
• 指定不要做什麼。
• 要求完成後摘要變更。

這會讓第一次 Build 更可控。

步驟 6：在 project（專案）裡檢查結果

Project（專案） 建立後，你會進入 Lovable editor。這裡至少有幾件事要看：

• Preview（預覽）：像使用者一樣操作你的 app。
• Chat：繼續給 Lovable 指令或提問。
• History：理解變更節奏，必要時回復。
• Project（專案） settings：查看專案資訊、設定 Knowledge、連 GitHub、調整 access、改名或刪除。
• Preview（預覽） toolbar：直接選取畫面元素，做視覺或文字調整。

第一次看 preview（預覽） 時，不要只看美不美。你要問：

• 這個頁面有沒有清楚說明產品是什麼？
• CTA 是否明確？
• 手機版是否可讀？
• 表單是否有基本狀態？
• 有沒有 Lovable 自作主張加了你沒要求的功能？

如果有，直接回到 chat 要它修正。

步驟 7：用 command palette 找東西

當 workspace（工作區）裡只有一個 project（專案），你可能不覺得 search 重要。等你做了十幾個實驗、三個客戶案、五個 demo，找 project（專案）就會變成成本。

Lovable 的 command palette 可以用 Cmd+K 或 Ctrl+K 開啟。它可以搜尋 projects、folders，也可以快速前往 dashboard（儀表板）、workspace（工作區）settings、connectors、theme switching 或切換 workspace（工作區）。

圖 2-2：Command Palette 把專案搜尋與常用導覽集中在一起；專案變多後，不必再靠側欄逐一尋找。

養成習慣：專案一多，就不要靠記憶找。用 search。

步驟 8：用 folders 管理專案

Folders 用來把 related projects 放在一起。這在寫書、做課程、接案、做產品實驗時都很實用。

你可以依用途分：

• book-examples
• client-demos
• internal-tools
• payment-experiments
• archived-ideas

也可以依狀態分：

• planning
• building
• published
• needs-review

但 folders 不是純視覺分類。它們也可能影響 project（專案）visibility。把 project（專案）加進 personal folder 或 workspace（工作區）folder 時，access 可能跟著改變。尤其在 Business 和 Enterprise plans 中，personal folders、workspace（工作區）folders、shared folders 的權限會影響誰看得到裡面的 projects。

所以整理專案前，先想清楚：這只是個人草稿，還是團隊應該看到？

圖 2-3：Projects 頁提供搜尋、排序、可見性與狀態篩選；資料夾會和專案卡片一起管理，右上角 Create 選單可建立新專案或新資料夾。

提示詞範例

範例 1：建立第一個安全範圍的小專案

我想建立第一個 Lovable 專案。
請為 [產品構想] 建置簡單的產品介紹頁。
頁面應包含主視覺、三項產品優點、一個使用案例、潛在客戶表單和常見問題。
請使用繁體中文。
目前不要加入登入、付款、資料庫或外部整合。
第一版請保持簡單，讓我可以熟悉 Lovable 的工作流程。

這個提示詞適合第一次 Build。它刻意排除登入、金流、資料庫和外部整合，避免第一個專案太複雜。

範例 2：從 dashboard（儀表板） 先進 Plan Mode

我想在 Lovable 建立一個新專案。
建置前，請協助我規劃第一版。
產品構想：[描述構想]
目標使用者：[描述使用者]
請建議最小但實用的版本，包括所需頁面、區塊和資料，以及應該延後的項目。
先不要寫程式碼。

這個提示詞適合還沒確定範圍時使用。

範例 3：檢查第一版 preview（預覽）

請把自己當成第一次造訪的使用者，檢查目前的預覽畫面。
確認產品價值是否清楚、行動呼籲是否明確，以及行動版版面是否容易閱讀。
修改前，請先列出發現的問題。
接著建議一小組必要的改善項目。

這個提示詞讓 Lovable 先 review，而不是馬上亂改。

實作練習

建立一個叫 AI Writer Landing 的第一個 Lovable project（專案）。

需求：

• 目標讀者是台灣內容創作者。
• 第一版只做 landing page。
• 不加登入。
• 不加金流。
• 不接 AI API。
• 只保留一個 lead form。

建議流程：

1. 在 dashboard（儀表板） 切到 Plan Mode。
2. 用 Pattern 2 要 Lovable 規劃第一版。
3. 確認 scope 後切到 Build Mode。
4. 用 Pattern 1 建立頁面。
5. 看 preview（預覽）。
6. 用 Pattern 3 要 Lovable review 第一版。
7. 修正一輪。
8. 把 project（專案）加到一個 book-examples folder。

預期結果：

• 你有一個可互動的 landing page project（專案）。
• 你理解 Plan 和 Build 的差別。
• 你知道如何從 dashboard（儀表板） 找回 project（專案）。
• 你知道 folder 會影響整理與可能的 access。

常見錯誤

錯誤 1：忘記自己在哪個 workspace（工作區）

如果你同時有個人 workspace（工作區）和公司 workspace（工作區），很容易把專案開錯地方。正式專案要先確認 workspace（工作區），尤其涉及 credits、billing、team access 和 GitHub sync 時。

錯誤 2：第一個提示詞太貪心

「做一個 SaaS，有登入、付款、後台、AI、SEO、部落格、會員系統」不是好的第一個專案。先做最小可理解版本，再逐步加功能。

錯誤 3：不看 access 設定

Project（專案） access 預設與 workspace（工作區）有關。團隊環境裡，別假設專案一定只有自己看得到。進入敏感專案前，先確認 visibility 和 share 設定。

錯誤 4：用資料夾只做美觀分類

Folders 也會牽涉 visibility 和 access impact。移動 project（專案）前，先看確認對話框，不要一路按確認。

錯誤 5：把 preview（預覽） 當成 publish

Preview（預覽） 是你在 editor 裡看到的互動畫面，不等於正式上線。Publish 會部署目前版本的 snapshot。改完之後如果要更新 live app，仍然需要重新 publish。

上線前檢查清單

• [ ] 確認目前所在 workspace（工作區）正確。
• [ ] 第一個 project（專案）scope 足夠小。
• [ ] 高風險功能沒有塞進第一版。
• [ ] 已先用 Plan Mode 釐清第一版。
• [ ] Build Mode（建置模式）提示詞有明確列出要做和不要做的事。
• [ ] Preview（預覽） 已在 desktop 和 mobile 視角檢查。
• [ ] Project（專案） access 已確認。
• [ ] Project（專案） 已命名清楚。
• [ ] 需要時已放進合適 folder。
• [ ] 你知道這個 project（專案）是否只是 preview（預覽），還是已 publish。

延伸閱讀

• 建立 Lovable 帳號
• Lovable Dashboard（儀表板） 總覽
• Lovable 快速開始
• 專案資料夾
• 專案搜尋與尋找

名詞解釋與延伸提問

• Dashboard（儀表板）：Lovable 中管理專案、工作區與入口操作的主畫面。
• Project（專案）：Lovable 裡的一個應用程式專案，包含程式碼、聊天紀錄、預覽與發布設定。
• Preview（預覽）：開發過程中用來檢查目前版本的預覽環境。
• Remix：複製既有專案成為新專案的方式，適合重新開始或建立變體。

如何問延伸問題

讀完本章後，建議用自己的專案情境繼續追問 Lovable 或本書作者：

• 「請根據我的專案，重寫本章的檢查清單。」
• 「我的目前版本最可能在哪三個地方失敗？」
• 「請把本章流程改成我下一次可以直接貼上的提示詞。」
• 「如果我要在兩天內完成 V1，哪些範圍應該先刪掉？」

嗨！我是 Wolke，曾任 Google Developer Expert（GDE，2019–2023） 與 LINE API Expert。我熱衷於研究 AI Agent、n8n 自動化工作流及全端開發架構，致力於將 AI 技術轉化為實際的生產力工具。

如果你喜歡這篇文章，歡迎透過以下方式與我交流，獲取更多技術實戰內容：

📚 技術著作：《實用的 Gemini API 開發點子書》，帶你運用 Gemini App、Google AI Studio、Gemini CLI 與 Antigravity IDE，打造 AI Agent 與實用產品。

📝 技術部落格：歡迎追蹤我的 Medium，我會持續分享 Agentic Automation、架構設計與實際開發的踩坑心得。

🎤 技術講座：我持續受邀至技術社群及研討會，分享 AI Agent、自動化工作流、DevOps 與全端開發實戰。曾於 2026 年 6 月 26 日的 DevOpsDays Taipei 2026 主講「不再只是寫腳本！讓 AI 代理人成為你的 SRE 最佳夥伴」工作坊。

如果你的企業、社群或學校正在尋找相關主題講者，歡迎私訊與我聯繫、洽談講座合作！

🎁 免費送 Lovable 額度給讀者！

我每個月會開放 10 個名額，每人 50 點 Lovable 額度，讓大家實際動手打造自己的網站或 App。

參加方式：

1. 訂閱本系列文章
2. 分享任一篇系列文章
3. 私訊分享截圖及你的 Lovable 帳號 Email

確認後，我會邀請你加入 Lovable workspace 並設定 50 點額度。名額有限，送完為止！